Developer CD Series 1997 January: Mac OS SDK

home *** CD-ROM | disk | FTP | other *** search

/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc / Developer Documentation / Human Interface / Human Interface Q & A / HI Q&A #5 < prev next >

Wrap

Text File | 1996-04-26 | 12.1 KB | 239 lines | [ttro/ttxt]

Q&A #5 Frequently Asked Questions from the WWDC By the Apple Computer OpenDoc Human Interface Team As published in the July 1995 Apple Directions Here's a collection of questions the OpenDoc Human Interface team was asked during the recent Worldwide Developers Conference (WWDC). We hope you'll find our answers helpful. Q: Where can I find a copy of the OpenDoc Human Interface Guidelines? A: They are on the 1995 WWDC Technologies CD that was distributed at the conference. To find the guidelines file, use the path 1995 WWDC Technologies:OpenDoc:Documentation:Human Interface:OpenDoc HI Guidelines. (To read the file, you'll need to install Adobe(TM) Acrobat Reader, which you can find on AppleLink.) We welcome your comments on these guidelines. These guidelines are up-to-date, with one exception: The section "Feedback for Cropped Parts" on pages 101-103 should have been deleted. Q: Why doesn't OpenDoc display the "not" symbol (circle with a slash) when a user is dragging objects over invalid drop targets? Displaying this symbol would be very helpful. A: According to the Macintosh Drag & Drop Guidelines, feedback shows users where they may drop, rather than where they may not drop. This is consistent with our general philosophy of using visual feedback to show users what actions are available at any given moment. However, other platforms (for example, Windows and OS/2) use an "invalid drop" feedback mechanism such as the one you describe. On those platforms, OpenDoc follows those user interface guidelines. Q: Why can't I select the root part in a document? I want to apply some operations to the entire document. A: Selection applies to content. At the root level of an OpenDoc document, users can select all of the content, but they can't select the container of the content--the document itself. To do that, they have to go to the Finder. (To help you understand what the root of an OpenDoc document is, consider a text document that has a spreadsheet part embedded in it. In this case, the document's root part is a text part.) Today, if users wish to modify the entire document, they can do so only to the extent that the application provides document-wide commands. OpenDoc is just the same, in that the ability to modify an entire OpenDoc document must rest in the part editor for the root part of that document. But OpenDoc is different from today's applications in that embedded parts can be turned into separate documents, and separate documents can be embedded as parts inside a container document. This is a powerful way of composing content, but it means that your parts may have somewhat different behaviors when they are embedded parts than when they are the root part. In particular, when your part is a root part, you may provide additional Document menu commands or capabilities such as window magnification. This is how you must implement document-wide commands, since users cannot select the entire document. In sum, when a part is the root part, it may provide a different set of capabilities or commands than when it is an embedded part. Some commands, such as Save or Document Info, apply only to the document as a whole; and some operations you definitely would not want to operate on the root part, such as Cut. Because you cannot select the root part, this situation cannot arise. Some Document commands, such as Print and Close, apply to the active window. Save a Copy applies to the active draft when a previous draft is frontmost. [Editor's note: A draft is a "snapshot" or a saved state of the document at a given moment. OpenDoc allows the user to view any draft of a document.] Q: How does OpenDoc handle saving the content of all of the parts in a document when one of the part editors that is being used in the document crashes? For instance, suppose I have two different types of content (which use two different editors) in a document. I edit the first of these; then, while I'm editing the second part, the first editor crashes. What happens to the changes that I put into the first part? Are they saved or lost? A: The behavior is the same as it is in today's application environment--if there's a crash, all unsaved changes are lost. Parts do not save independently; all of the parts in the document are saved in one file at once. Q: How does keyboard navigation work in a compound document? What Command key equivalents are used, and in what order do they navigate the hierarchy of embedded parts within a document? This is an issue for users who prefer to (or absolutely must) use the keyboard to navigate through their documents. A: This is a complex issue in OpenDoc because there is more than one sort of navigation. Navigation means moving the insertion point or selection within a single part, between a part and its container, or between a part and an embedded part. The arrow keys are typically used to move the insertion point within a single kind of content, as in today's applications. We haven't yet defined how to move between a container and one of its embedded parts. We are leaning toward using Command- Option-Up Arrow and Command-Option-Down Arrow for moving the insertion point up and down the part hierarchy. That is, when an embedded part is active and the user types Command-Option-Up Arrow, the parent part becomes active and the previously active part is selected. Likewise, when a part is selected, Command-Option-Down Arrow activates that part and places an insertion point as appropriate to that part. Tab might also be used to move among embedded parts. (Note, however, that there is some interaction between Tab and arrow key combinations in this context that we haven't yet defined.) We would like to know whether this may present a problem for your part. Q: The current selection model is annoying when you are doing things like page layout. How about if the resize handles were visible at the same time as the active frame border? A: In today's applications, you must first select an object and then choose actions (such as Cut, Copy, and Resize) to perform on the object. That interaction standard is preserved in OpenDoc, and is appropriate because most tasks involve editing content, rather than resizing and moving entire parts. When you are manipulating entire parts (as in page layout), the page layout part may provide a "layout mode." As we've said before, modes should be accessed through tools or menu commands. Additionally, you should include some visual indication that the user is in a given mode. Q: Why isn't there direct manipulation for scaling embedded parts? How about using "scaling" handles that are distinct from "cropping" handles? This might help users figure out what will happen if they move one of the handles. A: The short answer is: Using different handles for different behaviors is a great idea. However, we recommend clearly delineating multiple functions. Therefore, we recommend not mixing different kinds of handles on a frame. Instead, let users access the different functions as separate modes, through commands or tools. You may not be aware that both an embedded part and its container may cause the contents of a frame to be scaled (or rotated, skewed, and so on): If an embedded part's frame is resized, its editor must decide whether to crop or scale within the resulting frame shape. We strongly suggest that you use the cropping behavior as a default, rather than scaling. However, we realize that sometimes it may make sense to your part to scale content. A container must provide frame resizing (that is, cropping) for embedded parts. Additionally, a few containers (such as page layout or drawing) may also allow the user to change the rotation, scaling, and so on of embedded parts. To do this, we suggest your editor provide a tool or a command to enter a scale, rotate, or enter another mode. If you provide this capability through direct manipulation, you should change the appearance of the resize handles (to hollow squares or diamond shapes, for example) to provide visual feedback indicating that the user has entered a mode. At this point, when the user moves one of the handles, your editor would change the size of the embedded frame and change the external transform as appropriate (scale, rotate, skew, and so forth). Q: During one of the demos at the OpenDoc Human Interface session (#213) at the WWDC, when a PICT part was dropped into a drawing part, not all of the contents of the dropped PICT were visible--they were cropped. Why? A: When a part is added, it should ask its container for enough space to display its content. The container part dictates how much space the embedded part may occupy. If it isn't given a frame large enough to display all of its content, the embedded part should decide whether to display its content in a cropped format or, alternatively, request an additional frame (for example, a new page inserted in the document) from the container part. If the container part does not provide an additional frame, then the embedded part must crop itself. Generally the cropped content should be attached at the upper-left corner of the frame and cropped on the right and bottom edges as required. Q: In the demo just mentioned, each time the three PICTs were resized, they appeared to "re-center" themselves. Is this a feature or a bug? I think it's strange behavior. A: Oops! You caught us--the parts we used in our demo didn't display the correct behavior. The image should remain constant, and the user should be able to change the size and shape of the frame. The image shouldn't re-center itself when the frame is resized. Without this standard behavior, whenever a frame was irregularly shaped and then resized by means other than a corner resize handle, it would be difficult for the user to predict the result. Q: It's obvious that when an embedded part is cropped (not all the contents of the part are showing), the content that is visible is what gets printed. But suppose the part has scroll bars, like a list of addresses. What should be printed? A: In general, scroll bars are tools and, like other tools, should not appear in the printed document. However, this is up to you, the developer, to decide. We recommend that if the user can see the scroll bars on the screen, you print them. Otherwise, what is printed is different from what is on the screen. To allow the user to choose how to print, you should provide a command to show or hide the scroll bars, or provide a part editor preference for this purpose. A side note: If you follow the WYSIWYG model, only the contents currently visible (not necessarily all the contents of the part) should be printed. For more detail, consult the OpenDoc Human Interface Guidelines. Q: How should my part print? A: There are several aspects of printing. First, to basics: The Page Setup and Print dialog boxes contain options from the root part of the active window that apply to the entire document. We generally favor WYSIWYG, although there are exceptions depending on the kind of part. For example, movie and sound parts don't print very well. If your part displays some static content, and it doesn't have scroll bars, you should print what the user sees on the screen. If the content is dynamic--for example, the part displays database query results-- you should show the current value. Parts that have a preview or poster view, such as a movie, have the option of deciding to print that. This brings up print options. Today's documents often have options for controlling printing. These may appear on a custom Print dialog box, or perhaps on a Page Setup dialog box, or sometimes on a Print Options dialog box. When your part is embedded, you should not display a dialog box at print time asking for options. You must follow the options of the document, or options previously set by the user. So how does the user set options on a part? This is done through Print Settings, which may be provided as a menu command. These should also be available in the Part Info dialog box by means of the Settings button. In addition, your editor may have printing preferences that apply to all parts that use your editor. We will address more printing questions in future FAQs. __________________________________________________________ Copyright (c) 1995 by Apple Computer, Inc. All Rights Reserved.